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PREFACE 


This  is  the  final  report  for  work  conducted  by  Applied  Research 
Laboratories,  The  University  of  Texas  at  Austin  (ARL:UT),  under 
Contract  N00024-86-C-6134,  Task  12,  Project  18,  under  the  technical 
instruction  entitled  "Incorporation  of  the  Civilian  Community  in  GPS 
Operation  Capability  Reporting  System  Study".  This  report  is  in  four 
volumes.  One  of  the  primary  efforts  associated  with  this  contract  was 
the  development  of  an  interface  between  the  U.S.  Air  Force  and  the  civil 
community  which  will  allow  the  civil  community  access  to  information 
regarding  the  navigation  status  of  the  Global  Positioning  System  (GPS). 
This  interface,  or  point  of  contact,  operated  by  a  civil  organization  and 
referred  to  as  the  Civil  GPS  Service  (CGS),  will  serve  as  a  source  of 
information  from  the  GPS  Operation  Control  Segment  (OCS)  and  other 
sources,  and  disseminate  that  information  to  the  civil  community.  The 
Civil  GPS  Information  Center  (CGIC)  will  serve  as  the  operational  arm  of 
the  CGS  by  providing  GPS  status  information  to  the  civil  community. 

Volume  I.  "Determination  of  the  Requirements  of  the  Civil  GPS  User 
Community,"  by  Brent  A.  Renfro. 


Volume  I  summarizes  all  efforts  performed  by  ARl:UT  in  meeting  the 
specific  tasks  described  in  the  contract.  These  include 
(1)  establishing  a  steering  committee, 
determining  needs  of  GPS  civil  users, 

determining  data  and  data  sources  which  are,  or  will  be, 
available  to  the  CGS, 
conducting  a  CGS  user  workshop,  and 
developing  a  system  design  for  data  distribution. 


(2) 

(3) 


(4) 

(5) 


>■ 


Vol ume  I I . 


"Appendices  to  Volume  I,"  by  Arnold  J.  Tucker,  Brent  A. 
Renfro,  end  Jeanne  L.  Williams. 


Volume  II,  a  compendium  of  appendices,  addresses  the  results  of  the 
above  tasks  in  greater  detail. 

Volume  III.  "Interface  Control  Document  for  the  Civil  GPS  Service 
Interface  to  the  OPSCAP  Reporting  and  Management  System," 
by  Patrick  R.  Pastor. 

Volume  III  is  the  interface  control  document  (ICD)  defining  the 
requirements  related  to  the  transfer  of  GPS  navigation  data  between  the 
Operational,  Status,  and  Capability  (OPSCAP)  Reporting  and  Management 
System  (ORMS)  and  the  CGS. 

Volume  IV.  "Synopsis  of  Civil  GPS  User  Workshop  (22  September  1987)," 
edited  by  Arnold  J.  Tucker. 

Volume  IV  is  the  synopsis  of  the  GPS  Civil  User  Workshop  held  on 
22  September  1987  in  Colorado  Springs,  Colorado.  Included  in  this 
synopsis  are  transcripts  of  the  oral  presentations  made  during  the 
General  Session  and  also  summaries  from  the  various  discussion  groups 
which  were  chaired  by  members  of  the  CGS  Steering  Committee. 

For  additional  information  regarding  the  CGS,  direct  queries  to  the 
following  address. 


DOT/RSPA 

ATTN  DRT-1 

400  7th  St.,  S.W. 

Room  8405 

Washington,  D.C.  20590 
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I.  INTRODUCTION 

This  final  report  concerns  efforts  undertaken  by  Applied  Research 
Laboratories,  The  University  of  Texas  at  Austin  (ARL:UT),  for  the  Global 
Positioning  System  (GPS)  Joint  Program  Office  (JPO).  These  efforts  were 
performed  under  Contract  N00024-86-C-6134,  Task  12,  Project  18. 

Many  of  the  efforts  associated  with  this  contract  concern  the 
development  of  a  distribution  channel  by  which  the  civil  community  can  be 
informed  of  the  status  of  GPS  with  respect  to  its  usability  as  a 
navigation  aid.  The  requirement  for  this  channel  is  based  on  the  fact 
that,  while  current  federal  radionavigation  policy  (FRP)  establishes  that 
GPS  will  be  available  for  civil  use,  the  U.S.  Air  Force  (USAF)  has  no 
resources  available  for  the  support  of  civil  users. 

Developing  a  single  interface  between  USAF  and  the  civil  community 
will  allow  the  civil  community  access  to  appropriate  information  while 
minimizing  the  impact  on  USAF  resources.  This  point  of  contact,  operated 
by  a  civil  organization  and  hereafter  referred  to  as  the  Civil  GPS 
Service  (CGS),  will  serve  as  a  source  of  information  and  a  point  of 
contact  for  civil  users  of  GPS.  It  will  accept  information  from  the  GPS 
Operation  Control  Segment  (OCS)  and  other  sources,  and  disseminate  that 
information  to  the  civil  community.  It  will  also  serve  as  a  focal  point 
for  comments  and  questions  from  the  civil  community  regarding  GPS. 

The  tasks  associated  with  this  contract  include  the  following. 

(1)  Establish  a  CGS  steering  committee. 

(2)  Determine  needs  of  GPS  civil  users. 

(3)  Determine  data  and  data  sources  which  are  (will  be)  available 
to  CGS. 

(4)  Conduct  a  CGS  user  workshop. 

(5)  Investigate  methods  of  data  distribution  and  develop  system 
design  for  this  distribution. 
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(6)  Investigate  methods  by  which  the  CGS  might  be  made 
self-supporting. 

(7)  Prepare  a  dictionary/glossary  of  standard  GPS  terms. 

(8)  Compile  a  bibliography  on  differential  GPS. 

(9)  Compile  a  compendium  of  user  equipment. 

Tasks  1-7  are  directly  associated  with  development  of  the  CGS  while 
Tasks  8-10  concern  issues  which  may  supplement  the  CGS. 

This  report  is  separated  into  four  volumes.  A  summary  of  all  effort 
performed  on  the  above  tasks  and  details  of  the  system  design  are 
contained  in  this  volume,  Vol .  I.  Except  for  two  items,  the  complete 
results  of  the  remaining  efforts  are  contained  in  a  series  of  appendices 
in  Vol.  II.  The  interface  control  document  describing  the  interface 
between  the  Operational,  Status,  and  Capability  (OPSCAP)  Reporting  and 
Management  System  (ORMS)  and  the  CGS  (part  of  task  3)  is  Vol.  Ill  and  a 
synopsis  of  the  Civil  GPS  User  Workshop  is  Vol.  IV. 

As  currently  envisioned,  interactions  between  the  CGS,  the  USAF,  and 
the  civil  community  will  occur  at  several  levels.  These  relationships 
are  diagrammed  in  Fig.  1.  The  USAF  end  of  the  operational  interface  to 
the  CGS  will  be  handled  by  the  ORMS.  On  the  CGS  end,  the  ORMS  will 
interface  with  the  Civil  GPS  Information  Center  (CGIC).  The  CGIC  will  be 
the  operational  arm  of  the  CGS  concerned  with  providing  GPS  status 
information  to  the  civil  community.  Operation  of  the  CGIC  may  be 
contracted  to  a  private  sector  organization. 

As  GPS  becomes  operational,  it  is  possible  that  alternate  sources  of 
GPS  status  information  may  develop.  The  CGIC  will  provide  a  convenient 
channel  for  distribution  of  such  information  to  the  civil  community. 
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At  the  policy  level,  the  CGS  will  receive  feedback  from  the  civil 
community  concerning  operation  of  the  CGIC  and  also  serve  as  a  focal 
point  to  which  the  civil  community  can  express  their  concern  to  the  GPS 
management  in  the  USAF  Space  Command. 

Much  of  the  effort  expended  in  this  project  has  focused  on  the 
design  of  the  CGIC  and  the  interface  between  the  ORMS  and  the  CGIC. 
However,  in  performing  these  tasks,  accomplishments  were  realized  beyond 
those  originally  anticipated.  A  few  of  these  are  noted  in  the  following 
paragraphs. 

The  CGS  steering  committee,  under  the  chairmanship  of  DoD/DOT,  has 
been  established  and  should  continue  to  provide  assistance  to  the  CGS. 
The  steering  committee  was  first  convened  on  18  December  1986  and  met  six 
times  during  the  period  of  performance  of  this  contract.  The  steering 
committee  has  provided  guidance  to  ARL:UT  efforts  in  several  areas  and 
now  stands  ready  to  continue  providing  such  assistance  to  the  eventual 
designers  and  developers  of  the  CGS. 

Interactions  with  the  Federal  Systems  Division  of  IBM  (developers  of 
the  Military  ORMS)  not  only  provided  ARL:UT  with  information  required  to 
fulfill  its  tasking  with  respect  to  determination  of  available  data,  but 
also  provided  IBM  with  its  first  end-user  input  regarding  the  data  types 
which  might  be  of  interest  to  the  end  users  of  the  Military  ORMS. 

An  appreciation  has  been  developed  of  the  difference  between 
declaring  a  system  'available  for  civil  use'  and  the  level  of  information 
regarding  the  status  of  such  a  s>stem  which  must  be  available  if  the 
system  is  to  be  a  useful  tool.  This  distinction  has  been  a  major  focus 
of  discussion  in  the  steering  committee  even  though  it  has  rarely  been 
stated  in  such  terms. 


II.  STEERING  COMMITTEE 


In  conducting  this  effort  ARL:UT  received  guidance  from  the  CGS 
steering  committee.  This  committee  consists  of  representatives  from  a 
broad  cross-section  of  government  agencies  interested  in  GPS.  The 
committee  was  formed  by  the  GPS  JPO  in  December  1986  and  is  now  chaired 
by  the  U.S.  Department  of  Transportation  (DOT).  The  steering  committee 
charter  is  contained  in  Appendix  A  while  Appendix  B  contains  a  list  of 
the  members  of  the  steering  committee  and  the  participants  in  the 
steering  committee  meetings. 

During  the  period  of  performance  of  the  ARL : UT  contract,  the 
steering  committee  considered  several  topics  which  were  relevant  to  the 
ARL:UT  effort.  Among  those  topics  were 

(1)  possible  administrative  structure(s)  for  the  CGS, 

(2)  the  impact  of  GPS  security  policy  on  the  CGS, 

(3)  liability  considerations, 

(4)  the  need  for  an  interim  system, 

(5)  the  precise  time  and  time  interval  (PTTI)  community's  desire  to 
have  at  least  one  GPS  SV  remain  in  undegraded  operation, 

(6)  input  to  DOT  design  effort,  and 

(7)  names  for  CGS  and  CGIC. 

In  considering  possible  administrative  structures,  the  steering 
committee  was  concerned  with  finding  a  sponsor  organization  which  would 
regard  the  support  of  such  a  service  to  be  within  its  charter  while 
allowing  funding  of  the  CGS  to  be  distributed  among  several  agencies.  It 
was  eventually  decided  that  the  nature  of  the  CGS  required  that  the 
organization  controlling  the  CGS  be  a  civil  government  agency.  After  an 
exchange  of  letters  between  assistant  secretaries  of  Department  of 
Defense  (DoD)  and  DOT,  it  was  agreed  that  DOT  would  take  a  leading  role 
in  the  development  of  the  CGS.  Currently  this  is  interpreted  to  mean 
that  DOT  will  be  the  coordinating  agency  responsible  for  the  CGS,  but 


participation  of  other  agencies  will  be  encouraged.  Given  the  current 
fiscal  restraints  in  government  agencies,  participation  of  other  agencies 
will  probably  be  required  if  sufficient  funding  is  to  be  generated. 

In  discussing  the  data  to  be  provided  to  the  civil  community,  the 
steering  committee  recognized  that  there  may  be  information  which  the 
civil  community  desires  which  will  not  be  available  due  to  security 
considerations.  ARL.'UT  was  directed  to  concentrate  on  providing  transfer 
of  information  regarding  the  status  of  GPS  with  respect  to  navigation  and 
to  avoid  requesting  data  which  would  reveal  the  status  of  the  various 
ground  control  and  monitoring  segments  or  other  systems  associated  with 
GPS.  In  cases  where  a  clear  determination  was  not  possible,  the  data 
were  to  be  included  in  the  system  design  with  the  understanding  that  all 
requested  data  were  subject  to  exclusion  upon  USAF  review. 

The  committee  recognized  that  in  attempting  to  provide  GPS  status 
information  to  the  civil  community,  the  CGS  may  incur  liability  in  the 
event  it  fails  to  provide  agreed  services.  This  problem  remains 
unresolved  at  this  time.  Government  legal  departments  are  studying  the 
ramifications  of  systems  such  as  the  CGS  and  further  discussion  in 
committee  is  of  limited  use  until  such  studies  have  been  completed.  For 
the  moment,  the  committee  has  deemed  that  the  CGS  must  be  operated  in  a 
responsible  manner,  must  provide  for  archiving  the  information  provided, 
and  must  consider  the  traceability  of  any  and  all  information  it  decides 
to  provide  to  the  civil  users. 

The  committee  determined  that  there  is  a  need  for  an  interim  system. 
The  civil  communities'  need  for  information  will  increase  dramatically  as 
the  Block  II  satellites  become  operational.  The  ORMS  is  not  planned  to 
be  completely  operational  until  the  mid-1990  timeframe,  though  a  version 
of  the  ORMS,  with  limited  capabilities,  should  be  in  place  by  mid-1989. 
Therefore,  there  exists  a  gap  between  late  1988  and  mid-1990  when  the  CGS 
must  provide  information  to  users  without  the  benefit  of  the  sort  of 


system  discussed  in  this  report.  The  committee  sees  this  as  an 
opportunity  to  deploy  a  limited  system  which  will  allow  the  CGS  to  gain 
experience  in  the  operation  of  an  information  distribution  system  while 
allowing  the  end  users  to  indicate  the  usefulness  of  the  system. 

Mr.  D.  Allan  of  the  National  Bureau  of  Standards  (NBS)  has  proposed 
that  at  least  one  SV  be  left  in  undegraded  mode  to  support  international 
time  transfer  applications.  Currently,  eight  of  ten  "national"  atomic 
clocks  use  GPS  to  compare  their  time  measurements;  62%  of  the  over  250 
atomic  standards  used  in  computing  international  atomic  time  are  using 
GPS  for  comparison. 

During  the  performance  period  of  this  contract,  DOT  (in  particular 
the  Transportation  Systems  Center),  has  been  working  on  the  design  of  the 
administrative  structure  of  the  CGS.  The  steering  committee  has 
regularly  been  updated  on  this  effort  and  has  provided  valuable 
suggestions  and  comments.  As  part  of  this  effort,  there  has  been  an 
exchange  of  letters  between  DoD  and  DOT  at  the  undersecretary  levei,  in 
which  DoD  invited  DOT  to  be  responsible  for  developing  and  maintaining 
the  CGS  and  DOT  agreed  to  take  a  leading  role  in  such  development. 

During  the  steering  committee  meeting  of  27  August  1987,  the 
committee  adopted  the  names  "Civil  GPS  Service"  (CGS)  and  "Civil  GPS 
Information  Center"  (CGIC).  Before  this  time,  the  CGS  was  referred  to  as 
the  Independent  Civil  Service  (ICS),  and  the  CGIC  as  the  Civil 
Operational,  Status,  and  Capability  Reporting  System  (Civil  OPSCAP) .  A 
name  change  was  also  initiated  by  the  military;  Military  OPSCAP  is  now 
known  as  Operational,  Status,  and  Capability  (OPSCAP)  Reporting  and 
Management  System  (ORMS). 


III.  DATA  AND  DATA  SOURCES 


During  the  first  meeting  of  the  CGS  steering  committee,  it  was 
suggested  that  all  information  the  CGS  received  from  the  USAF  come  from 
the  ORMS.  The  ORMS  would  have  all  of  the  relevant  information  available 
as  a  function  of  performing  its  task  and  the  ORMS-CGS  interface  would 
provide  a  one-to-one  contact  between  the  military  and  civilian  systems. 
As  an  example  of  the  data  which  would  be  available  by  such  a  channel, 
Mr.  B.  Winn  of  Aerospace,  Inc.,  presented  a  brief  summary  of  data 
quantities  which  the  ORMS  could  provide. 

ARL:UT  was  tasked  with  starting  a  tentative  list  of  data  quantities 
and  developing  an  interface  control  document  (ICD)  describing  the 
information  flow  from  the  ORMS  to  the  CGIC.  This  ICD  is  presented  in 
Vol .  Ill  of  this  report. 

In  developing  the  ORMS-CGIC  interface  ARL:UT  received  support  from 
the  Federal  System  Division  of  IBM  in  Gaithersburg,  Maryland.  This 
Division  developed  the  Master  Control  Station  (MCS)  and  is  currently 
developing  the  ORMS.  During  several  meetings  and  telephone 
conversations,  IBM  provided  valuable  advice  regarding  the  information 
available  from  the  OCS,  the  easiest  methods  of  accessing  the  data,  and 
the  data  which  would  be  of  most  use  to  users. 

Several  tradeoffs  were  considered  in  designing  the  ORMS-CGIC  ICD. 
Two  major  areas  where  competing  constraints  led  to  tradeoffs  concerned 
the  amount  of  data  available  to  the  civil  community  and  the  distribution 
of  the  processing  and  transmission  burdens  between  the  ORMS  and  the  CGIC. 

The  civil  community  contains  several  groups  of  users.  Some  of  these 
groups  are  quite  knowledgeable  regarding  satellite  navigation  and  geodesy 
and  desire  to  have  very  complete  information  regarding  GPS  status  in  the 
broadest  sense.  Other  users,  while  realizing  that  the  CGIC  is  not 


designed  to  resolve  the  integrity  issue,  would  like  information  to  be 
available  as  soon  as  the  ORMS  has  access  to  the  data  with  minimal  delay 
in  passing  data  through  the  CGIC. 

Both  of  these  desires  conflict  with  GPS  data  security  requirements. 
In  general,  only  data  regarding  the  performance  of  GPS  with  respect  to 
navigation  status,  and  whatever  other  items  a  user  with  a  navigation 
receiver  could  derive  from  the  signal,  will  be  available  through  the 
CGIC.  Even  within  these  restrictions,  some  of  these  data  may  be  delayed 
several  hours  or  days  before  being  cleared  for  distribution. 
Furthermore,  since  the  ORMS  will  contain  classified  data,  all 
transmissions  to  the  CGIC  will  have  to  be  cleared  before  transmission. 
This  will  probably  make  it  desirable  to  send  data  from  the  ORMS  to  the 
CGIC  in  bursts  accumulated  over  time  rather  than  send  the  information  as 
it  becomes  available. 

The  conflict  between  processing  and  transmission  comes  about  because 
the  current  design  for  the  CGIC  calls  for  a  minimal  system  which  is 
capable  of  fulfilling  the  civil  community's  needs  with  a  minimum  of  data 
processing.  Carried  to  an  extreme,  this  would  shift  large  amounts  of 
data  processing  to  the  ORMS  and  increase  the  data  transmission 
requirements  beyond  those  which  could  be  reasonably  supported.  The  ICD 
presented  in  Vol.  Ill  attempts  to  balance  the  data  processing  load  on  the 
CGIC  against  the  transmission  requirements  for  the  ORMS-CGIC  link. 

A  draft  version  of  the  ICD  was  discussed  at  the  Civil  GPS  User 
Workshop  (see  below)  where  user  community  response  was  solicited.  This 
draft  version  was  also  distributed  to  manufacturers  of  GPS  equipment  in 
order  that  they  might  review  the  ICD  for  completeness  and  usefulness  of 
the  data  set. 


IV.  GPS  CIVIL  USER  SURVEY 


A  GPS  Civil  User  Survey  was  developed  for  distribution  by  the  civil 
user  community.  This  survey  had  two  major  goals:  first,  to  determine  if 
there  was  interest  in  such  a  system,  and  second,  to  determine  the 
opinions  of  the  user  community  with  respect  to  the  data  the  CGIC  would 
provide  and  the  method(s)  by  which  the  data  would  be  distributed. 


The  survey  was  developed  by  ARL:UT  and  interested  civil 
organizations  during  the  spring  of  1987.  Feedback  from  the  sponsor 
agency  and  the  CGS  steering  committee  was  instrumental  ir  determining  the 
final  form  of  the  survey.  During  the  summer  and  fall  of  1987  several 
organizations  used  this  survey  to  determine  the  concerns  of  their  members 
about  GPS.  The  responses  of  these  distributions  were  made  available  to 
ARL:UT  for  analysis  and  inclusion  in  this  report.  A  list  of 
participating  organizations  is  included  in  Table  I. 


By  the  time  analysis  of  the  survey  began  (1  March  1988),  178  survey 
responses  had  been  received.  Responses  were  received  from  16  foreign 
countries.  The  survey  and  an  analysis  of  the  responses  is  included  in 
Appendix  C,  "Analysis  of  GPS  Civil  User  Survey"  (see  Vol .  II). 


When  analysis  of  the  survey  began,  some  organizations  were  still 
expecting  further  responses.  If  these  responses  are  forwarded  to  ARL:UT, 
they  will  be  passed  on  to  the  CGS  steering  committee  or  whatever 
organization  the  committee  designates  so  that  these  data  may  be  retained 
for  future  analysis. 
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TABLE  I 

ORGANIZATIONS  WHICH  PARTICIPATED  IN  THE 
CGS  CIVIL  USER  SURVEY 


The  Institute  of  Navigation 
Texas  Instruments 

Airline  Electronic  Engineering  Committee 
Technical  Support  Group  (NATO) 

NAVSTAR  GPS  Steering  Committee  (NATO) 

Navigation  Subgroup  IV  (NATO) 

Land  Survey  Division  of  the  Royal  Institution  of  Chartered  Surveyors 
Institut  fur  Angewandte  Geodasie 
Deutsche  Gesellschaft  fur  Ortung  und  Navigation 
(German  Institute  of  Navigation) 

Federal  Armed  Forces  Geographic  Office 

U.S.  Naval  Observatory  Computer  Bulletin  Board 

Yuma  Proving  Grounds  Computer  Bulletin  Board 


V.  GPS  CIVIL  USER  WORKSHOP 


ARL:UT  conducted  a  GPS  Civil  User  Workshop  to  inform  users  regarding 
the  CGS  and  the  CGIC  and  to  gain  feedback  from  the  potential  end  users  of 
the  system.  The  workshop  was  conducted  in  Colorado  Springs,  Colorado,  on 
22  September  1987  in  conjunction  with  the  ION  Satellite  Division  First 
Technical  Meeting.  This  meeting  provided  an  excellent  opportunity  to 
address  a  group  of  potential  users  since  the  major  focus  of  the  meeting 
was  the  development  and  uses  of  GPS.  A  synopsis  of  the  workshop  is 
included  in  Volume  IV  of  this  report. 

The  workshop  started  with  a  series  of  presentations  by  the  GPS  JPO, 
DOT,  and  ARL:UT.  In  these  presentations,  the  users  were  informed  of  GPS 
policy  with  respect  to  civil  use,  the  current  status  of  DOT  planning 
regarding  a  Civil  GPS  System,  and  the  CGIC  design  being  developed  by 
ARL:UT. 

Following  the  presentations,  the  workshop  split  into  several 
discussion  groups.  The  discussion  groups  were  organized  around  GPS 
applications  and  were  chaired  by  members  of  the  CGS  steering  committee. 

After  the  discussion  sessions,  the  workshop  adjourned  for  lunch  and 
reconvened  in  the  afternoon  for  a  closing  summary.  In  the  summary 
session,  the  discussion  group  chairmen  summarized  the  discussions  which 
took  place  in  their  groups. 

While  Vol .  IV  contains  more  complete  details  regarding  the  workshop, 
the  following  list  summarizes  the  results  of  the  workshop. 

(1)  The  participants  agreed  on  the  need  for  a  means  by  which  civil 
users  can  obtain  GPS  navigation  status  information. 

(2)  No  significant  changes  were  proposed  regarding  the  data  types 
included  in  the  design  of  the  CGIC.  Some  minor  changes  in 
nomenclature  were  recommended. 

15 


' '} , '  V 


(3)  The  participants  did  suggest  a  number  of  goals  for  the  CGS 
beyond  the  operation  of  the  CGIC.  Included  in  the  suggestions 
were  the  following. 

(1)  CGS  should  be  the  civil  point  of  contact  and  serve  as  an 
advocate  for  civil  users. 

(2)  CGS  should  provide  a  database  large  enough  to  handle 
information  on  both  a  general  and  specific  basis, 
including  publishing  general  GPS  information. 

(3)  CGS  should  provide  traceability  of  data  and  promote 
standards. 
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VI.  DESIGN  OF  THE  CGIC 

To  fulfill  the  CGS  goal  of  distributing  information  on  the  status  of 
GPS  navigation  capability,  some  means  (or  several)  must  exist  to 
distribute  that  information.  For  the  CGS,  the  means  will  be  the  CGIC.  As 
part  of  the  ARL : UT  effort,  a  system  design  for  the  CGIC  has  been  prepared 
and  is  presented  here. 

This  design  has  been  evolving  for  some  time,  and  several 
organizations  have  contributed  to  the  design  by  sharing  their 
experiences.  The  idea  of  a  CGIC  operated  by  the  CGS  was  proposed  at  the 
first  steering  committee  meeting  by  the  DOT.  One  of  the  advantages  of 
the  concept  was  that  the  administration  of  the  CGS  could  be  kept  within 
the  government  while  the  operation  of  the  CGIC  could  be  contracted  out. 

Existing  computer  bulletin  boards  at  USNO  and  at  the  Yuma  Proving 
Grounds  distribute  GPS  status  information.  While  neither  of  these  sites 
was  interested  in  becoming  the  CGIC,  both  sites  were  very  helpful  in 
sharing  their  experiences  and  problems. 

Early  in  the  study  it  was  discovered  that  the  National  Oceanic  and 
Atmospheric  Administration  (NOAA)  office  in  Boulder,  Colorado,  operates 
an  information  distribution  system  for  solar  events.  This  system,  called 
solar  environmental  data  and  distribution  system  (SELDADS),  is 
responsible  for  providing  a  variety  of  different  users  with  solar 
information  in  a  timely  fashion  and  uses  several  different  kinds  of 
distribution.  The  SELDADS  administrators  and  operators  were  quite 
willing  to  share  their  experiences  and  much  of  this  design  is  based  on 
the  SELDADS  system. 

As  discussed  in  the  introduction,  the  CGIC  is  controlled  by  the  CGS, 
receives  GPS  navigation  status  data  from  the  ORMS,  stores  and  formats 
these  data,  and  serves  as  a  data  distribution  point  to  the  users  (see 
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Fig.  1).  In  addition,  there  may  be  other  data  input  sources  in  the 
future  should  the  civil  community  develop  reliable  sources  of  information 
relevant  to  GPS. 


Several  products  will  be  produced  by  the  CGIC.  The  largest  effort 
will  be  to  operate  a  computer  bulletin  board  which  will  provide  GPS 
navigation  status  information  to  callers  in  digital  form.  Additionally, 
the  CGIC  will  be  prepared  to  answer  phone-in  questions  verbally  and 
respond  to  written  correspondence.  Through  both  the  above  channels,  the 
CGIC  will  serve  as  a  focus  of  civil  user  feedback  to  the  USAF  on 
operational  matters. 

Other  distribution  CGIC  services  may  include  the  distribution  of  the 
following  sorts  of  information: 

(1)  educational  materials  on  GPS, 

(2)  archival  information  on  9-track  tape,  and 

(3)  broadcast  of  GPS  navigation  status  information  on  WWV. 

Number  of  Users 

To  design  an  appropriate  system,  there  must  be  an  estimate  of  the 
number  of  users  who  will  access  the  system.  In  forming  an  estimate  of 
the  number  of  users  the  following  information  has  been  considered: 

(1)  results  of  the  GPS  Civil  User  Survey, 

(2)  experience  with  the  TRANSIT  system,  and 

(3)  an  independent  estimate  of  the  future  number  of  civil  users. 

The  results  of  the  survey  indicate  that  there  will  be  at  least 
100  potential  users  of  the  CGIC  whenever  it  becomes  available. 

The  TRANSIT  system,  a  currently  operational  satellite  navigation 
system,  has  been  used  by  the  civil  community  since  1968.  Since  that 
time,  the  Navy  Astronautics  Group  has  been  projecting  the  use  of  TRANSIT 


every  two  years.  The  latest  projection  (in  terms  of  number  of  user  sets) 
is  shown  in  Fig.  2.  It  should  be  noted  that  shortly  after  TRANSIT  became 
available  several  hundred  sets  were  in  use  and  the  number  of  sets  grew 

dramatically  as  the  cost  and  size  of  sets  diminished.  GPS  is  more 

accurate  and  convenient  than  TRANSIT,  and  the  advantages  of  electronic 
miniaturization  are  already  available  to  manufacturers  of  GPS  equipment. 
Therefore,  the  growth  in  civil  use  of  GPS  may  be  more  dramatic  than  that 
in  TRANSIT. 

In  April  1986,  Canadian  GPS  Associates  produced  the  chart  shown  as 
Fig.  3  which  illustrates  the  estimated  growth  of  GPS  users  over  time.  By 
this  estimate,  there  may  be  more  than  10,000  users  by  the  end  of  1990. 

While  each  of  these  sources  only  yields  an  estimate  of  the  number  of 
users,  it  is  clear  that  the  potential  exists  for  an  explosive  growth  of 
the  GPS  civil  user  community.  Therefore,  it  is  important  that  the  design 
of  the  CGIC  allow  for  the  initial  system  to  be  sufficient  to  handle  the 
needs  af  current  users  and  be  expandable  enough  to  meet  future 

requirements. 

Computer  Bulletin  Board 

The  system  design  for  the  CGIC  computer  bulletin  board  is  based  on 
the  following  assumptions  and  requirements. 

(1)  The  available  data  quantities  are  specified  in  the  ORMS-CGIC 

ICD.  Possible  data  volumes  range  from  302  kbytes/day  to 

2012  kbytes/day. 

(2)  The  system  shall  be  capable  of  operating  24  hours  a  day,  every 
day  of  the  year.  The  system  will  be  manned  16  hours  per  day, 
every  day  of  the  year. 

(3)  The  system  shall  be  capable  of  storing  data  covering  several 
days  of  transfers  from  the  0RMS. 
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(4)  The  system  shall  be  capable  of  handling  multiple  requests  for 

service  at  one  time.  To  start  with,  it  should  be  able  to 

handle  at  least  ten  callers  at  a  time. 

(5)  The  system  shall  always  be  ready  to  respond  to  the  ORMS.  A 
second  input  channel  will  be  available  for  inputs  from  other 
sources. 

(6)  The  system  shall  be  capable  of  off-line  mass  storage  of 

archival  data. 

(7)  The  system  shall  allow  for  the  greatest  practical  ease  in 

growth . 

Hardware  Design 

Figure  4  is  a  block  diagram  of  the  hardware  design.  The  system  is 
built  around  a  MicroVAX  II  with  the  following  peripherals: 

(1)  an  appropriate  hardware  interface  to  the  ORMS, 

(2)  serial  multiplexer  to  connect  external  input  processors  to  the 
CGIC, 

(3)  two  high  capacity  hard  disks, 

(4)  two  9-track  tape  drives,  and 

(5)  a  12-line  auto-answer  modem. 

The  MicroVAX  provides  a  relatively  low  cost  start-up  configuration 
while  allowing  for  upward  growth  through  the  entire  range  of  the  DEC  VAX 
family.  This  is  important  because  a  great  deal  of  growth  may  be 
necessary  if  the  GPS  civil  user  community  experiences  the  growth 
anticipated.  By  starting  at  the  bottom  of  a  family  of  compatible 
computers,  it  will  be  possible  to  expand  the  capability  of  the  hardware 
without  rewriting  the  software  package. 

The  MicroVAX  uses  either  of  two  popular,  wel 1 -supported  operating 
systems,  VMS  or  ULTRIX,  for  which  many  applications  already  exist.  This 
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will  make  it  easier  to  speed  development  of  the  system  by  allowing  for 
the  purchase  of  commercial  packages  for  many  of  the  software  items  the 
system  requires.  Having  a  standard  operating  system  will  also  reduce  the 
training  time  necessary  for  new  operators. 

Finally,  DEC  service  agreements  are  usually  readily  available  in  the 
United  States  and  service  agreements  can  be  obtained  guaranteeing  up  to 
98%  up-time.  This  will  enhance  system  reliability. 

It  is  important  that  the  CGIC  ensure  that  no  user  of  the  CGIC  can 
disturb  operation  of  the  ORMS.  Therefore,  the  ORMS-CGIC  interface  is 
specified  as  a  RJE  (remote  job  entry)  type  of  interface.  In  this 
situation,  the  ORMS  will  control  all  interactions  on  the  ORMS-CGIC  line. 
The  ORMS  design  has  not  been  developed  to  the  point  where  the  preferred 
method  of  communication  has  been  determined,  but  some  similar  existing 
interfaces  to  the  OCS  use  the  IBM  3780  protocol  specified  in  this  design. 

The  ORMS  interface  would  connect  to  a  phone  line  capable  of 
9600  baud  communications  and  the  interface  and  the  phone  line  would  be 
dedicated  to  the  use  of  the  ORMS.  In  this  fashion,  the  CGIC  is  available 
to  receive  data  from  the  ORMS  any  time  the  CGIC  computer  is  running. 
Given  that  the  data  transfer  requirements  for  the  interface  range  from 
302  kbytes/day  to  2012  kbytes/day,  this  interface  will  only  be  active  for 
11-72  min  each  day. 

Other  input  sources  can  be  handled  by  routing  the  input  to  an  IBM 
PC-compatible  computer  equipped  with  an  auto-answer  modem.  (This  scheme 
has  been  used  successfully  by  the  SELDADS  system  for  several  years.)  As 
these  inputs  are  not  as  critical  as  the  ORMS  input,  the  sending  party  may 
receive  a  busy  signal  when  attempting  to  pass  data  to  the  system,  but 
enough  PC  capacity  can  be  added  to  the  system  to  permit  reasonable  access 
to  the  data.  The  PC  allows  data  quality  checking  and/or  reformatting  to 
be  performed  without  adding  overhead  to  the  MicroVAX.  The  PCs  also 
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prevent  the  direct  entry  of  data  into  the  CGIC  from  outside  sources. 
Data  entering  the  PCs  can  be  monitored  for  correctness  before  being 
allowed  onto  the  CGIC  proper. 

While  the  high  capacity  hard  disks  would  be  sufficient  to  store  the 
anticipated  volume  of  data,  two  hard  disks  are  advisable  for  redundancy. 
It  is  assumed  that  the  operating  system  and  the  operational  software 
require  approximately  half  of  a  disk  (and  that  each  disk  contains  a 
complete,  functional  set)  and  that  the  remainder  of  the  space  is 
available  for  data  storage.  This  is  more  than  sufficient  to  provide  for 
30  days  of  the  maximum  data  volume  of  2012  kbytes/day  specified  in  the 
ORMS-CGIC  ICD.  At  the  minimum  data  volume  of  302  kbytes/day,  it  will 
support  240  days  of  data. 

The  9-track  tape  drives  provide  archival  storage  capability  and  the 
capacity  to  copy  data  for  transport  to  other  systems.  There  are  also  two 
drives  for  redundancy. 

The  auto-answer  modems  provide  the  hardware  to  allow  the  remote 
users  to  connect  to  the  CGIC.  Several  manufacturers  provide  this 
capability  for  a  MicroVAX.  It  is  strongly  recommended  that  the  modems  be 
of  a  type  that  plug  directly  into  the  chassis  of  the  host  computer  and 
that  sufficient  expansion  space  be  reserved  for  additional  modems.  The 
number  of  modems  in  the  sample  system  is  based  on  an  assumed  worst  case 
estimate  of  having  100  users  each  accessing  300  kbytes/day  (roughly  the 
size  of  the  minimum  transfer/day  from  the  ORMS).  Assuming  that  the  users 
have  2400  baud  modems,  the  data  transfer  rate  will  be  on  the 
order  of  120  bytes/s.  At  such  a  rate,  each  user  will  require  about 
45  min  to  complete  their  interaction  with  the  CGIC.  To  serve  100  such 
users  within  an  eight  hour  period  with  a  25%  margin,  the  CGIC  will 
require  at  least  12  modems.  This  comes  from  the  following  calculation: 

(100  users  X  .75h/user)  /  (8  hours  *  .75)  =  12.5, 
where  the  answer  represents  the  number  of  lines  which  must  be  available. 


Software  Design 

Based  on  the  above  hardware  design,  the  software  design  can  be 
broken  into  the  following  items. 

(1)  The  operating  system 

(2)  The  software  for  handling  the  ORMS  interface 

(3)  Handling  interactions  with  CGIC  users  via  the  modems 

(4)  Software  in  PCs  for  checking/reformatting  data 

(5)  Operator  control  software  for  monitoring  the  system, 
archiving/de-archiving  data,  and  performing  other  maintenance 
functions 

(6)  Transfer  software  for  moving  data  from  the  PCs  to  the  MicroVAX 

As  stated  before,  a  standard  operating  system  should  be  used  to 
allow  the  use  of  the  widest  possible  set  of  pre-existing  software  and 
experienced  personnel.  Either  VMS  or  ULTRIX  should  be  acceptable. 

The  software  for  handling  the  ORMS  interface  is  responsible  for 
recognizing  requests  for  service  from  the  ORMS  and  for  proper  storage  of 
incoming  data.  To  continue  with  the  example,  DEC  supports  a  2780/3780 
protocol  emulator  for  its  synchronous  interface  hardware. 

The  software  which  handles  interactions  with  CGIC  users  must  be 
capable  of  monitoring  the  status  of  the  multiple  modems,  detecting 
incoming  requests,  finding  the  appropriate  data,  and  transmitting  that 
data  back  to  the  user.  It  is  envisioned  that  this  software  will  be  in 
the  form  of  a  bulletin  board  program  which  allows  the  user  to  request 
subsets  of  the  data  which  has  been  transferred  to  the  CGIC  from  the  ORMS. 
Data  sets  of  interest  to  many  users  will  be  "packaged"  by  the  CGIC  to 
make  selection  easy.  While  the  bulletin  board  may  allow  users  to  leave 
messages  for  the  system  operator,  users  should  not  be  allowed  to  leave 
messages  to  each  other,  and  it  is  important  that  users  not  be  allowed  to 
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enter  data  which  could  change  the  information  in  the  CGIC  via  this 
channel . 

The  software  in  the  PCs  for  data  quality  assurance  and  data 
reformatting  might  best  be  supplied  by  the  same  organization  as  supplies 
the  data.  PCs  are  widely  available  and  development  of  these  routines  by 
the  originator  of  the  data  will  reduce  the  need  for  a  programmer  at  the 
CGIC  and  probably  result  in  better  interpretation  of  the  data. 

The  operator  control  software  may  consist  of  one  program  or  many 
depending  on  the  final  design.  The  major  goals  are  to  allow  the  operator 
to  monitor  performance  and  integrity  of  the  system,  maintain  a  correct 
disk  file  structure,  and  handle  the  archiving  and  de-archiving  of  data  to 
and  from  the  tape  devices.  This  software  will  also  be  responsible  for 
the  transfer  of  data  from  the  input  handling  PCs. 

Staffing  and  Other  Considerations 

Staffing  of  the  CGIC  will  require  at  least  three  operators  and  a 
senior  operator.  During  weekdays,  there  shall  be  at  least  one  operator 
for  each  8  hour  shift  and  the  senior  operator's  shift  shall  overlap  the 
busiest  part  of  the  day  and  cover  the  change  of  shift  for  the  operators 
and  the  usual  time  for  transfer  of  periodic  data  from  the  ORMS.  During 
weekends,  there  will  be  only  one  person  serving  as  operator  at  a  time. 

If  it  is  necessary  to  allow  for  the  possibility  of  performing 
software  upgrades  to  the  CGIC  after  it  becomes  operational,  a  programmer 
will  need  to  be  hired  to  implement  these  changes.  It  should  also  be 
noted  that  a  separate  software  development  facility  should  be  purchased 
with  similar,  but  reduced  capabilities.  The  operational  CGIC  should  not 
be  used  to  develop  and/or  test  software  so  as  to  avoid  lapses  in  proper 
operation. 
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The  CGIC  should  have  access  to  at  least  two  phone  numbers  for  voice 
communication.  While  both  can  be  regular  telephones,  one  number  should 
be  reserved  for  use  by  calls  to/from  the  ORMS  while  the  other  line  can  be 
for  calls  to/from  other  parties.  Once  again,  this  will  ensure  that 
information  from  the  ORMS  is  handled  in  a  timely  manner. 

Cost/Benefit  Considerations 

There  are  several  areas  of  the  design  where  cost/benefit  tradeoffs 
have  been  made.  Among  these  areas  are 

(1)  hours  of  operation, 

(2)  amount  of  data  analysis  performed, 

(3)  number  of  users  supported,  and 

(4)  amount  of  data  kept  on  line. 

The  system  design  calls  for  the  system  to  be  manned  16  hours/day. 
Expanding  operation  to  24  hours/day  would  call  for  recurring  costs  on  the 
order  of  another  two  man/years  per  year,  or  roughly  $200, 000/year.  The 
system  will  be  available  for  civil  access  24  hours/day,  and  it  should  be 
sufficiently  reliable  that  unmanned  operation  for  eight  hours/day  would 
not  result  in  frequent  outages  of  information  to  the  civil  community. 
Therefore,  at  least  in  the  initial  start-up  phase,  it  is  felt  that 
16  hours/day  is  sufficient. 

Another  tradeoff  area  is  in  the  amount  of  data  processing  and/or 
analysis  performed  by  the  CGIC.  The  system  design  calls  for  a  fairly 
simple  system  which  forwards  data  received  from  outside  sources  with  a 
minimum  of  reformatting  and  no  examination  or  analysis.  Starting  any 
level  of  data  processing  or  analysis  would  probably  require  migration  to 
a  larger,  more  capable  computer,  and  would  certainly  require  the  hiring 
of  a  data  analyst.  All  of  the  staff  discussed  above  are  skilled  in 
system  operation  and  data  communications,  and  would  likely  not  have  the 
scientific  background  to  support  processing  and  analysis  of  GPS  data. 


Therefore,  supporting  a  five  day  a  week,  16  hours/day  processing  and 
analysis  operation  would  require  at  least  two  man  years/year. 

The  number  of  civil  users  supported  is  limited  by  the  capability  of 
the  CGIC  computer  and  number  of  access  lines  available  to  the  civil 
community.  One  of  the  reasons  for  picking  the  DEC  VAX  family  is  that 
there  is  a  computer  at  the  bottom  of  their  price  line  which  has  a  long 
line  of  upwardly  compatible  machines  above  it.  This  should  reduce  the 
costs  associated  with  upgrading  the  system  to  those  costs  necessary  to 
purchase  and  install  the  necessary  hardware  upgrades.  Costs  associated 
with  transporting  and/or  converting  software  should  be  negligible. 

The  amount  of  data  kept  on-line  in  the  CGIC  is  selected  such  that 
most  users  will  have  had  time  to  transport  data  from  the  field  to  their 
main  data  processing  center.  If  the  users  put  the  data  through  an 
initial  quality  check  immediately  upon  arrival,  it  should  still  be 
possible  to  query  the  CGIC  regarding  anomalies  and  find  that  the 
corresponding  data  are  still  on-line. 


Estimated  Cost  of  CGIC 

There  are  two  components  to  calculating  the  costs  of  the  CGIC.  The 
first  is  the  non-recurring  cost  and  the  second  is  the  recurring  cost. 
The  first  cost  concerns  the  hardware  procurement  and  the  software 
development  necessary  to  build  the  system.  The  second  is  dominated  by 
the  cost  of  the  personnel  required  to  run  the  system.  Table  II  presents 
the  estimated  cost  of  the  hardware  outlined  in  the  system  design  and  the 
software  which  would  be  purchased  "off-the-shelf".  Table  III  presents 
the  estimated  cost  of  the  software  development  effort  associated  with  the 
minimal  "bulletin  board"  system  specified  in  the  design.  These  tables 
taken  together  are  the  estimated  cost  of  setting  up  the  CGIC. 


TABLE  II 

ESTIMATED  NON-RECURRING  COSTS  FOR  HARDWARE  AND  SOFTWARE 

FOR  SYSTEM  DESIGN 


HARDWARE 

Description 

Main  System 

(MicroVAX  II  with  5  Mbytes 
memory,  console,  cartridge  tape, 
and  dual  floppy) 

3780  interface 

Phone  lines 

154  Mbyte  disks 

1600  bpi  9-track  tape  drives 

Terminal s 


HARDWARE  TOTAL 


SOFTWARE 

Description 


Cost 

1988  Dollars] 
$  32,075 


755 
15,000 
14,490 
25,620 
1,670 
$  89,610 


Cost 

1988  Dollars] 


I 

M 


1 

License  for  16  user  VMS  operating  system 

$  13,650 

1 

VMS  media  and  documentation 

1,500 

m 

1 

License  for  2780/3780  protocol  emulator 

3,045 

a 

1 

2780/3780  protocol  emulator  media  and 
documentation 

450 

• 

1 

License  for  VMS  FORTRAN 

3,255 

--  v 

1 

Media  and  documentation  for  VMS  FORTRAN 

500 

• 

1 

Database  software 

16,000 

"  4  ITJ 
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1 

Bulletin  board  software 

5,000 

'>*>■! 

SOFTWARE  TOTAL 

$  43,400 

1 

1 
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TABLE  III 

ESTIMATED  COST  OF  SOFTWARE  DEVELOPMENT 


TASKS 


Establish  OCS  <->  CGIC  link 
Construct  database  to  serve  provided  ICD 
Establish  database  <->  BBS  link 


MANPOWER  (1988  Dollars) 

1  Systems  Analyst  (0.75  myear) 

1  Senior  Programmer  (0.75  myear) 


SUBTOTAL 


Administrative  Overhead 


TOTAL 


EFFORT 


4  man/months 
6  man/months 
6  man/months 


$  27,000 

22.500 

49.500 
X  2.5 

$123,750 


GRAND  TOTAL  $256,760 


Table  IV  shows  the  estimated  cost  of  operating  the  CGIC.  The 
estimated  total  for  setting  up  the  CGIC  is  $243,000.  The  recurring  cost 
of  operation  is  estimated  at  $333,000. 


TABLE  IV 


ESTIMATED  COST  OF  OPERATING  CGIC 
(RECURRING  COSTS  PER  YEAR) 


HARDWARE 

I 

MAINTENANCE  (1988  Dollars! 

Main  System 

(MicroVAX  II  with  5  Mbytes  memory, 
console,  cartridge  tape,  and  dual 
floppy) 

$ 

3,100 

1 

3780  interface 

200 

12 

Phone  lines 

2,550 

2 

154  Mbyte  disks 

1,500 

2 

1600  bpi  9-track  tape  drives 

2,150 

2 

Terminal s 

300 

HARDWARE  TOTAL 

r 

9,800 

SOFTWARE 

1 

MAINTENANCE  (1988  Dollars! 

VMS  operating  system 

$ 

4,000 

1 

2780/3780  protocol  emulator 

800 

1 

VMS  FORTRAN 

600 

1 

Database  software 

4,000 

1 

Bulletin  board  software 

500 

SOFTWARE  TOTAL 

r 

9,900 

PERSONNEL  (1988  Dollars! 

(Assumptions:  OCS  data  only,  12  hours/day  operation,  6  days/week) 

1 

System  manager  (base  salary) 

$ 

35,000 

3 

System  op  rators 

90,000 

SUBTOTAL 

$125,000 

Administrative  Overhead 

X 

2.5 

PERSONNEL  TOTAL  $312,500 

$332,200 


GRAND  TOTAL 
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